home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ShareWare OnLine 2
/
ShareWare OnLine Volume 2 (CMS Software)(1993).iso
/
elecmail
/
bgnetb12.zip
/
BGNET.TXT
< prev
next >
Wrap
Text File
|
1993-03-23
|
20KB
|
435 lines
BGNET 1.0 BETA 12 TUE 23 MAR 93
--------------------------------
I'm going to start taking lessons from Boris Yeltsin. (I've probably just
butchered his name like mad), but, the net status fields have pushed me to
the limit. In the past two weeks I've had four people send me sample QWK
bags that had net status in it. Each bag was using a different format.
Rather than spend the next two years trying to figure out what I'm supposed
to do with all the bloody net status fields, I have taken a different step:
BGNET NO LONGER CHECKS FOR NET STATUS IN QWK PACKETS!
I urge you to get permission from the sysop of the other board before
importing the mail to your BBS, but, I can't stop you from doing it
unauthorized anymore. I got the Orkin Man to spray BGNET so BGNET no
longer even knows what "net status" means. It doesn't care. It will
import any d*mn packet you tell it to import now.
A few cosmetic changes to both the display and log file made it into this
version. Now that we have the stupid net status nonsense out of the way, I
can spend time improving the display, log file, and increasing the speed of
imports and exports. That'll be another day.
Please note the new REGISTER.FRM for BGQWK/BGNET is included in this
ARJ file. You can now register with your CREDIT CARD (Discover, VISA,
Mastercard, and now, EVEN AMERICAN EXPRESS).
BGNET 1.0 BETA 11 WED 13 JAN 93
--------------------------------
It's been two months since the last release of BGNET. I've fixed some bugs
and made some changes and improvments. I should be writing a documentation
to BGNET as it gets more stable.
1. The net status determination engine has been rewritten yet again. I
saw a bug report that indicated BGNET would not recognize net status in
conference 0. It should be now. Whoever reported that bug, please let me
know if this beta fixes it.
If you wish to import GT Power packets with BGNET, you will have to ask
the sysop of the BBS you are calling to change line 299 of his SYSOP.BBS
file from the default of:
"Produced by Qmail...Copyright (c) 1987 by Sparkware. All Rights Reserved"
... and change it to:
"MarkMail and RNet, The Logical Choice!"
Doing this will make BGNET think the GT Power on the other end is really
a MarkMail door which gives global net status to all conferneces. This
does NOT have to be done if the other GT Power system offers the BGQWK
door.
2. BGNET will now import messages (especially on big QWK packets) more
quickly than before as BGNET will build a single index to use for all
conferences rather than doing it one conference at a time as in the last
few betas. This, however, limits the maximum number of messages in one
QWK packet to 4096. If this number is too small, let me know and I'll
make it bigger.
3. Added support for two environment variables ... QWKDIR and REPDIR.
BGNET will default to looking for QWK files in the directory specified by
the TP= directive in the GT.CNF file. REP files default to be created in
the directory specified by the UP= directive in the GT.CNF file. To
override this, simply do the following in AUTOEXEC.BAT or the batch files
that start up BGNET:
SET QWKDIR=J:\RELAY\BACKUP
SET REPDIR=D:\NETTEST
Will force BGNET to look for QWK files in J:\RELAY\BACKUP rather than
C:\GT\SPECREQ (which is specified by TP= in GT.CNF). REPDIR is similar.
Remember, using these environment variables is totally OPTIONAL.
4. Attempted to fix, yet again, the problem with PKZIP and PKUNZIP not
being found at times. The PKZIP and PKUNZIP paths will be shown on the
screen so the sysop knows what's been looked for where.
5. BGNET was writing to BGQWKpid.LOG rather than BGNETpid.LOG. OOOPS!!!
Fixed.
6. If the work directory cannot be deleted for some reason, rather than
erroring out with a Runtime 162 or Runtime 005, the error will be taking
care of gracefully and added to the log file.
7. Some minor changes were made for debugging purposes.
Special copies of BGNET were made for two people that helped with problems
with the latest MarkMail Beta. The "fix" cannot be found in this public
beta as it would compromise the security of the MarkMail door.
BGNET 1.0 BETA 10 SAT 7 NOV 92
--------------------------------
It's been three months since the last BGNET ... so here's some new stuff:
1. IMPORTANT ... THIS IS NOT A DROP IN REPLACEMENT ...
Your hubid.CNF configuration files must be CHANGED ... BGNET now allows
you to use up to FOUR different export and import taglines. This is
provided so those people that pick up more than one network from the
same hub system can configure the taglines and make only one run to the
same hub system rather than many more. Here is an example of the NEW
format of the BGNET.CNF file:
I1=001/070: Computech
E1=001/040: Tranquility Base - 713-893-9124 - Houston, Tx
I2=LinkNet: INCOMING ....
E2=LinkNet: The Great American Tokad
-----+-------+[n=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
0003 | 01576 | 1=F:\MAIL\TEST,
0217 | 00205 | 2=F:\MAIL\E20-343,
0134 | 03435 | 1=F:\MAIL\BATMAN,
0135 | 02034 | 1=F:\MAIL\RETURNS,
The only changes you'll have to make is edit the "EX=" to "E1=" and
edit the "IM=" to "I1=" then go and put a "1=" in front of all your
message areas in the hubid.CNF file.
The way the above example file would work, any mail from your system for
the 3, 134, and 135 conferences will have a "Tranquility Base..."
tagline appened to it. Any outgoing mail in the 217 conference will
have "The Great American Tokad" tagline appended to it.
2. All registered users of BGQWK are now registered users of BGNET! BGNET
will check for a valid BGQWK registration in the BGQWK.KEY file and if it
finds it, you'll be registered. Remember BGNET and BGQWK look for the
BGQWK file in the LANPATH (if you have one), or the GTPATH (if you don't).
3. BGNET now verfies that both the GTPATH and DOS PATH exist before
continuing with the initialization.
4. BGNET was not loading all conference information from the CONTROL.DAT
file properly (it never loaded the last conference), and, in some cases,
caused certain conferences that should have had net status marked
without it. Special thanks to Bob Wallace for identifying this.
5. The work directory will now be called \BGNETpid.WRK. The swap file name
will be BGNETpid.SWP and the new log filename will be BGNETpid.LOG where
"pid" is your LAN pid number (it'll be "0" if you don't have a LAN).
This is the same convention BGQWK uses (except NET is replaced with QWK).
6. Messages with GT's internal ";rep" commands in them are filtered of the
";rep" component while exported.
7. This copy of BGNET.EXE is not compressed with DIET. You may want to
compress the EXE file with DIET, PKLITE or another EXE compressor to save
space.
BGNET 1.0 BETA 9 WED 29 JUL 92
--------------------------------
1. Tony Reynolds reported a problem with BGNET importing packets made with
the MarkMail door. A fix for this problem has now been put in place.
2. A few people reported problems with BGNET running PKZIP. I have no idea
what could be causing that, but BGNET now puts a little debug information
to see if we can find anything out.
BGNET 1.0 BETA 8 WED 22 JUL 92
--------------------------------
1. FINALLY --- BGNET now utilizes EMS 3.2/4.0 or disk swapping when shelling
to run PKZIP/PKUNZIP, etc to give you every bit of memory you can get ...
when shelled, BGNET only uses about 3K of memory giving the rest of your
conventional memory for the child program.
2. FINALLY --- BGNET will now create a LOG file detailing what exactly is
happening. With this, there are too new command line options:
'O', when used, will DISABLE logging.
'P', when used, will PIPE logging into the GT.LOG file.
Obviously, the O and P command line options CANNOT be used at the same
time. Remember how to specify command line options?
BGNET hubid /x:options d:
(Where "x" is E, I or R and "options" are the indiviual command line
options you wish to use smushed together). Example:
BGNET c-tech /i:kp5 f:
Would run BGNET for the C-TECH hub in IMPORT mode using F: as the work
drive. The "kp5" would indicate to kill protect ('K') incoming messages,
pipe ('P') all logging information in the GT.LOG file and use GT 15 style
message bases ('5').
3. A status line has been added that shows the hub id, mode of operation,
MES or MSG compatability, EMS/disk usage amount, and registration
information.
4. A bug in the last beta ... If NETFLAGS.DAT existed, BGNET was having a
cow trying to read the file since I "fixed" it in beta 7, <grin>.
There's still more to come ... Stay tuned, same bat time, same bat channel.
BGNET 1.0 BETA 7 THU 16 JUL 92
--------------------------------
Oh No! Another BGNET release in just two days! AHHHHHHHHHH! :)
1. If seems as if some mail doors are not including the NETFLAGS.DAT file
for net status information, but rather are putting the information in
another place. This other place is now checked. If BGQWK reports that the
packet does not have net status and you are positive your hub sysop has
granted you net status, please call me at 713-893-9320 and let me know. It
seems as if there is not really a "standard" for net status. If anyone
knows any other QWK door authors that know about net status, please let me
know so I can try to get in touch with them.
2. Some cosmetic changes (when importing, the actual conference names are
now read in from the CONTROL.DAT file).
Again, this is just a quick bug release ... many more features will be
coming soon to a BGNET near you ...
BGNET 1.0 BETA 6 TUE 14 JUL 92
--------------------------------
It's been about two months since the last beta release of BGNET and that's
been surprising because I just found a whole slew of nasty bugs. I've been
so busy with BGQWK lately I haven't had had much time to work on it, but
hopefully that will change now.
1. Major problems with the status status identification logic: it wasn't
working at all! Now, the NETFLAGS.DAT file will be read by BGQWK after
unpacking the MESSAGES.DAT file from the .QWK on an import run. You can
not import messages into conferences you aren't granted net status for.
Leave me messages in E02/758 (BG Support) if this seems to be causing
problems. I've examined a few net status packets, and none of them seem
to work the way they are supposed to, <ugh>.
2. Support for registration keys is finally back. If you sent in a BGNET
registration, you can call my board and open door four to pick up a combo
BGQWK/BGNET registration key. The file name will be BGQWK.KEY (yes,
that's not a typo, even if you have NOT registered BGQWK).
3. The name of the work directory will now be \BG$NET$.pid rather than
\BG$WORK$.pid so as to not confuse work directories with BGQWK and BGNET.
(I'll probably end up changing BGQWK's work directory to \BG$QWK$.pid
in BGQWK Beta 33).
4. The "dummy packet" identification scheme was pretty much messed up big
time. I've corrected it and done a little fine tuning to make detection
quicker than before. I also noticed a SHARE violation if this happened,
and that has been corrected as well.
5. Some minor cosmetic changes.
This has been a mainly bug fix release. I still have many many more things
to do with BGNET such as adding EMS/disk swapping support, support for
'kludged' line entries, etc. I'll get to it soon.
BGNET 1.0 BETA 5 TUE 19 MAY 92
--------------------------------
1. Several new conference options have been created for help with people
trying to pick up FidoNet echos. New options:
S - strip high bits on characters on export
A - translate ANSI <ESC>[ to `[ psuedo-ansi on export
F - use one line export tag line rather than two, example:
without F -> ---
■ BgNet 1.0ß1 ≈ Tranquility Base - Houston, Texas
with F -> --- BgNet 1.0ß1 - Tranquility Base - Houston, Texas
To use these options, like BGQWK, place the letters of the options you
wish to use for a conference after the comma. Example:
-----+-------+[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
0041 | 01443 | D:\MAIL\TEST,SAF
0040 | 01455 | D:\MAIL\TESTII
0039 | 01443 | D:\MAIL\LANTEST,A
2. Some users have requested that there be a way to tell BGNET *not* to
create a null packet when no outgoing messages are available. I have added
a command line option to do this, but I wouldn't recommend doing this. I
like the way the null rep packet logic works. To force BGNET to *not*
create an empty rep packet when no outgoing messages are available, do this:
bgnet tranquil /e:n f:
where "tranquil" is board id (looked up in TRANQUIL.CNF file) and the /E:N
means export messages and do *not* create empty packet and F: is the work
drive used.
BGNET 1.0 BETA 4 SUN 3 MAY 92
--------------------------------
1. Jim Kreyling discovered the TOMCAT mail door did not like packets
created with BGNET because the header of the REP .MSG packets were padded
with null characters rather than spaces.
2. Douglas Pippel discovered that imported messages with psuedo-ansi codes,
`[, were not being transformed into the true-ansi codes, <esc>[.
BGNET 1.0 BETA 3 WED 22 APR 92
--------------------------------
<GRIN>
1. Well, Douglas Pippel informed be that BGNET was bombing out if more than
so many message bases were used. I saw this problem with the /e export
function and fixed it, but forgot to check it in the /r reset and /i import
functions. Those functions should now be fixed.
BGNET 1.0 BETA 2 TUE 21 APR 92
--------------------------------
1. When imported messages BGNET was continuously "saving last exported
pointers". This was only supposed to happen after all messages had been
imported, not after everyone. Fixed.
2. The number of messages imported is now displayed.
3. BGNET was suffering the same problem TNet was suffering when exporting
mail. I kept opening numerous MESSAGE.CTL files and forgetting to close
them resulting in a too many files error. This is now fixed on export.
4. When importing messages, if the QWK header has the net tagline flag
marked as true, BGNET will not add the "import tag". I believe this is
what other QWK network utilities do.
BGNET 1.0 BETA 1 SUN 19 APR 92
--------------------------------
Welcome to an all new beta test. Because TNet will no longer support the
UTI interface, I have decided to write my own QWK network message tosser
for GT Power systems. (This program essentially does the same thing as
GTQWK aka MERLIN). I have tested this somewhat but not much at all. I
canalbalized many of the routines from BGQWK, so if BGQWK didn't give you
any LAN problems, this shouldn't (in theory). This supports GT 15 and
beyond just as BGQWK does. Since I have decided to start this project, any
reference to "TNet" and "UTI" in the original BGQWK.DOC file are now
obselete and will be replaced at a later date.
Well, how do we use this thing? I've tried to make this as easy to use as
possible, so here is the example syntax:
BGNET hubid /x[:options] d:
...where "hubid" is the eight letter identification used by the hub on its
QWK and REP packets. where "/x" can have the following values:
/e export (bag messages)
/i import (distribute messages)
/r reset (reset last exported pointers to highest message number)
...where "d:" is a drive letter for the work drive. A temporary directory
will be created (d:\BG$WORK$.pid) the same as used in BGQWK. (This is okay
since BGQWK and BGNET will never be used at the same time on one specific
node). If you have a RAM drive, I would highly recommend you use that.
...where options can be:
5 use gt 15 message format (individual msg files)
k kill protect incoming messages
Here's my batch file used to send and receive mail for TexasNet:
@echo off
del c:\gt\specreq\hopper.qwk
bgnet hopper /e f:
copy c:\gt\uploads\hopper.rep d:\relay\backup
%gt% hopper.scr *xxxx-xxxx
if exist c:\gt\specreq\hopper.qwk goto success
echo *** COMMUNICATIONS FAILTURE WITH TEXAS NET HUB ***
goto end
:success
copy c:\gt\specreq\hopper.qwk d:\relay\backup
bgnet hopper /i f:
del c:\gt\specreq\hopper.qwk
del c:\gt\uploads\hopper.rep
:end
cd %gtpath%
The way this batch file works is like so:
a. delete any old .qwk file in my downloads directory
b. export any new messages
c. copy this new (or updated) rep packet into my backup directory
d. run gt and execute the script to transfer the rep packet and download
a new qwk packet
e. check to see if we actually downloaded a .qwk packet ...
if not, exit the batch file with a communications failure
if so, continue...
f. copy this qwk packet to my backup directory
g. import the packet
h. delete the .qwk packet and .rep packet from their directories
Notice that I do not delete the original .REP file if a communications
failure occured. When BGNET is started in export mode, it will check to
see if a .REP file already exists. If it does, BGNET will add any new
outgoing messages to it rather than overwriting it, so it will be your
responsibility to delete the .REP if the transfer was successfully. If you
use my batch file as an outline for yours, this should be handled
automatically.
So, what about the config file?
Here is my C-TECH.CNF file that BGNET uses when I want to send/receive GT
Power mail from Russell's board:
im=001/070: Computech
ex=001/040: Tranquility Base - 713-893-9124 - Houston, Tx
-----+-------+[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
0006 | 01389 | D:\MAIL\E10-037
0003 | 01237 | D:\MAIL\E02-758
0001 | 01779 | D:\MAIL\E00-001
0010 | 00779 | D:\MAIL\E10-009
0011 | 01119 | D:\MAIL\E01-009
0012 | 00220 | D:\MAIL\E20-002
0013 | 00007 | D:\MAIL\NETMAIL
NOTICE that the config file is called C-TECH.CNF (not BGNET.CNF)! BGNET
looks for this file in the directory that your USER.CTL file is kept in
(lanpath on LAN systems, GTPATH otherwise).
IM= is the import tagline (which is added to incoing messages). EX= is the
outgoing tagline (which is added to outgoing, exported messages).
The first column of numbers is the number of the conference at the Hub
system your calling. Note their are FOUR placeholders not just three as in
the BGQWK.CNF file. (This is because on some PC Board systems, some people
have up to 8192 conferences!) The second number is the last exported
message number. This number will be automatically mantained by BGNET as
needed. I suggest setting it to "00000" when first installing BGNET. And,
the third row, as you can probably tell, is the pathname to the message
base on your system.
Well, that's about all for now. This program was put together very quickly
so it's probably full of bugs. Russell has been out of town, so I haven't
had a chance to do any alpha testing. The display is not pretty---pretty
much just gives you raw information.